[Fix] Slack follow-ups disappear after human side discussions - #2407

​Opened on behalf of @daniel-lxs. Follow up by mentioning @roomote-roomote, in the web UI, or in Slack.

Related issue

Maintainer-requested prototype; no linked public issue.

Why this PR exists

• A maintainer explicitly invited this PR in the linked issue or discussion
• I am a maintainer / this is internal Roomote work

The Slack interjection gate discarded human discussion before Fast could judge whether to participate. After a peer mention, even a later plain-name request could remain invisible until the bot spoke again. This separates message visibility from permission to reply or act.

What changed

• Admit eligible human replies in established Slack Fast threads, including peer discussion, while retaining linked-user authorization and legacy task/unrelated-channel routing. Stop marking Fast threads as requiring explicit mentions after peer discussion.
• Use quiet-participation guidance: human-to-human discussion normally calls ignore_event without replies, reactions, integrations, notes, or task launches. Explicit mentions, direct plain-name address, replies to Roomote, and clear contextual follow-ups can engage. This is contextual model judgment, not a name-matching regex.
• Persist fetched thread context with durable follow-ups and supply it to both native steering and queued turns as supplemental context with existing deduplication.
• Preserve quiet eligibility across queued delivery and native instruction boundaries without silently dismissing outstanding directed requests. Ambient asides cannot supersede parked or interrupted requests; DMs retain response-required behavior.

Impact: Fast can follow the discussion without treating every message as an invitation to speak. Eligible ambient messages now incur inference and durable-context storage cost, and may add latency under load. Quiet/no-work behavior is prompt-guided rather than a hard tool-permission restriction. This prototype does not backfill historical dropped events or change other providers' ingress policy.

How it was tested

• API Slack event suites: 142 tests passed, including full side-discussion admission, plain-name follow-up admission, legacy gates, and busy context capture.
• Fast service and prompt suites: 342 tests passed, including silent completion and mixed directed/ambient native batches.
• SDK durable admission/delivery suites: 94 tests passed, including context forwarding, queued quiet eligibility, and parked-request preservation.
• Shared event-schema suite: 3 tests passed, including compatibility with old events without a context snapshot.
• Package typechecks passed for API, cloud-agents, SDK, and types. Pre-push oxlint, residual ESLint, full fast typechecks, and knip passed.
• Tests use controlled model outputs. No live Slack/model replay or production event-fate telemetry was available; actual model silence accuracy and inference cost remain to be evaluated. Browser screenshots would not prove this backend behavior and were not captured.

Checklist

• The PR title follows the repo convention: [Fix], [Feat], [Improve], [Refactor], [Docs], or [Chore] followed by a user-facing description
• This PR is small and scoped to one change
• pnpm lint and pnpm check-types pass locally
• I added tests or included a clear manual validation note above
• I removed secrets, tokens, private keys, and customer data from code, logs, and screenshots
• If this change should appear in the changelog, I ran pnpm changeset

The exact full commands in the checklist were not run; the pre-push equivalents and affected-package typechecks passed. No changeset was added for this prototype.